Meshed networks of wirelessly interconnected lighting poles or other lighting devices, sensor devices, or load devices will become the infra-structure for smart city or housing services such a light management, traffic management, and air quality monitoring. City wide networks may consist of tens of thousands of lighting poles that relay traffic via multi-hop communication protocols. The size of these networks makes their deployment an undertaking which challenges the current state of the art in network design and networking protocols.
Similarly wirelessly connected lighting networks will provide easy to install and energy efficient lighting within professional and residential buildings. Additional benefits of such lighting networks are in lighting management and data-based services. Data must be routed along multi-hop paths between nodes in the lighting poles and the coordinator node. As the networking nodes are resource (memory) constrained, routing protocols based on flooding are needed.
In professional wireless lighting applications, it is a common usage for one controller to send one command to a large amount of destination devices in a wireless mesh network, such as ZigBee network, so that all devices are reacting at the same time, e.g., to switch on or off all lights. A mesh network broadcast algorithm, e.g., the ZigBee data broadcast function, is used to send the message from the controller to all other devices in the network, which may be located far from each other and rely on forwarding to pass data from one device to the other (multi-hopping). The broadcast algorithm is based on a network flooding mechanism to send one packet repeatedly to all devices, and each device will forward the received packet and re-broadcast it to others so that in the end all devices in the network will receive the packet at least once, no matter how far away the device is located in the mesh network.
In a mesh network, two network functions are depending on the broadcast algorithm: route discovery and data broadcast. The broadcast transmission will flood the network with many packets, the packet storm, for a long duration. The flooding will thus generate a storm of packets in the network in the hope to cover as much devices as possible, and, as a side effect, during the packet storm, other commands sent to the network may be stalled, since the packet storm may occupy a large portion or most of the available network bandwidth. A mechanism to control the duration can be implemented to limit the time of the storm lasting in the network, thus a balance of quality and efficiency is achieved. More specifically, the broadcast algorithm may use the broadcast radius to control the duration. Each packet may carry a radius parameter and reduce it by one when being forwarded. Thus, a broadcast packet storm will die out when the last packet floating in the network has a value of one for the radius parameter. Usually a default large value is chosen for the radius hoping to cover most different network layouts. When a network has a layout with long path (high number of hops) between two nodes, a large value of the radius parameter is needed to cover the whole network. When the path is short, a small value of the radius parameter can sufficiently reach all nodes, but remove the redundant packets.
For any given network layout, a smallest possible radius parameter is needed, which will sufficiently ensure the broadcast coverage, and at the same time use efficiently the available network bandwidth, that is, to reduce the packet storm duration as short as possible. Thus this radius parameter must be calculated for a given network layout, instead of using a fixed default value. Besides, the network operation conditions may change overtime, for example, with external environment changes, such as adding new radio frequency (RF) interference sources, the radius parameter needs to be calibrated over time. An option to find out the best value for the radius parameter is to try the broadcast transmission with different values of the radius parameter, and compare the results of the broadcast so as to choose the smallest and with sufficient reliability. The broadcast result has two aspects: coverage and duration. The broadcast coverage is the status of all devices whether the broadcast message is received or not, the broadcast duration is the time between the first packet and the last packet in circulation. The difficulty lies in the mechanism of broadcast coverage calculation, e.g., how to return the status of all devices (received or missing) to the broadcast message initiator.
Because the above broadcast control is implemented, and with issues like the network bandwidth limitation, wireless interference, from network itself or other sources, or packet collisions etc., some devices may still not receive the broadcasted message. While many studies have been conducted on improvements of a broadcast algorithm itself, either on coverage or on efficient network bandwidth usage, few studies are related to detecting and reporting the missing devices after the broadcast. The reporting mechanism is important for mission critical applications, for example, a “switch all lights off” command issued to the mesh network, all lights shall be switched off, and the operator shall be notified if there are any lights not receiving the commands, and a remedy can be immediately followed, otherwise, without this mechanism, the operator may leave few lights on unnoticed.